home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pppext-x25-01.txt < prev    next >
Text File  |  1993-07-08  |  12KB  |  443 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        W A Simpson
  8. Internet Draft                                                Daydreamer
  9. expires in six months                                          July 1993
  10.  
  11.  
  12.                               PPP in X.25
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is the product of the Point-to-Point Protocol Working
  19.    Group of the Internet Engineering Task Force (IETF).  Comments should
  20.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  21.  
  22.    Distribution of this memo is unlimited.
  23.  
  24.    This document is an Internet Draft.  Internet Drafts are working
  25.    documents of the Internet Engineering Task Force (IETF), its Areas,
  26.    and its Working Groups.  Note that other groups may also distribute
  27.    working documents as Internet Drafts.
  28.  
  29.    Internet Drafts are draft documents valid for a maximum of six
  30.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  31.    other documents at any time.  It is not appropriate to use Internet
  32.    Drafts as reference material or to cite them other than as a
  33.    ``working draft'' or ``work in progress.''
  34.  
  35.    Please check the 1id-abstracts.txt listing contained in the
  36.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  37.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  38.    current status of any Internet Draft.
  39.  
  40. Abstract
  41.  
  42.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  43.    transporting multi-protocol datagrams over point-to-point links.
  44.  
  45.    This document describes the use of X.25 for framing PPP encapsulated
  46.    datagrams.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                  expires in six months                  [Page i]
  59. DRAFT                         PPP in X.25                      July 1993
  60.  
  61.  
  62. 1.  Introduction
  63.  
  64.    CCITT recommendation X.25 [2] describes a network layer protocol
  65.    providing error-free, sequenced, flow controlled, virtual circuits.
  66.    X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
  67.    and 6256.  The capabilities that are provided by X.25 are considered
  68.    unnecessary and overly complex.
  69.  
  70.    PPP also uses ISO 3309 HDLC as a basis for its framing [3].
  71.  
  72.    At one time, it had been hoped that PPP HDLC frames and X.25 frames
  73.    would co-exist on the same links.  Equipment could gradually be
  74.    converted to PPP.  Subsequently, it has been learned that some
  75.    switches actually remove the X.25 header, transport packets to
  76.    another switch using a different protocol such as Frame Relay, and
  77.    reconstruct the X.25 header at the final hop.  Co-existance and
  78.    gradual migration are precluded.
  79.  
  80.    There are still ISO-lated pockets of existing X.25 links, and some
  81.    interest in bringing the advantages of the PPP multiprotocol datagram
  82.    service to this venue.
  83.  
  84.    When X.25 is configured as a point-to-point circuit, PPP can use X.25
  85.    as a framing mechanism, ignoring its other features.  This is
  86.    equivalent to the technique used to carry SNAP headers over X.25.
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Simpson                  expires in six months                  [Page 1]
  114. DRAFT                         PPP in X.25                      July 1993
  115.  
  116.  
  117. 2.  The Data Link Layer
  118.  
  119.    This specification uses the principles, terminology, and frame
  120.    structure of the "Multiprotocol Interconnect on X.25 and ISDN in the
  121.    Packet Mode" [4].
  122.  
  123.    The purpose of this specification is not to document what is already
  124.    standardized in [4].  Instead, this document attempts to give a
  125.    concise summary and point out specific options and features used by
  126.    PPP.
  127.  
  128.  
  129. 2.1.  Frame Format
  130.  
  131.    Since both PPP and X.25 use ISO 3309 as a basis for framing, the full
  132.    X.25 header is easily substituted for the smaller HDLC header.  The
  133.    fields are transmitted from left to right.
  134.  
  135.     0                   1                   2                   3
  136.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  137.    +-+-+-+-+-+-+-+-+
  138.    |  Flag (0x7e)  |
  139.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  140.    |    Address    |    Control    |D|Q| SVC# (hi) |   SVC# (lo)   |
  141.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  142.    |p(r) |M|p(s) |0|  NLPID(0xcf)  |         PPP Protocol          |
  143.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  144.  
  145.  
  146.    NLPID
  147.  
  148.       This field contains a one octet Network Layer Protocol Identifier
  149.       (NLPID), which identifies the network layer protocol encapsulated
  150.       over the X.25 virtual circuit, in accordance with the Subsequent
  151.       Protocol Identifier (SPI) in ISO/IEC TR 9577 [5].  The value used
  152.       for PPP is <TBD> CF hex.
  153.  
  154.    Protocol Field
  155.  
  156.       The Protocol field is two octets and its value identifies the
  157.       protocol encapsulated in the Information field of the frame.  The
  158.       field is transmitted and received most significant octet first.
  159.  
  160.  
  161. 2.2.  Modification of the Basic Frame
  162.  
  163.    The Link Control Protocol can negotiate modifications to the basic
  164.    frame structure.  However, modified frames will always be clearly
  165.  
  166.  
  167.  
  168. Simpson                  expires in six months                  [Page 2]
  169. DRAFT                         PPP in X.25                      July 1993
  170.  
  171.  
  172.    distinguishable from standard frames.
  173.  
  174.    Address-and-Control-Field-Compression
  175.  
  176.       Because the Address and Control field values are not constant, and
  177.       are modified as the frame is transported by the network switching
  178.       fabric, Address-and-Control-Field-Compression MUST NOT be
  179.       negotiated.
  180.  
  181.    Protocol-Field-Compression
  182.  
  183.       When Protocol-Field-Compression is negotiated, both the NLPID and
  184.       Protocol fields are compressed.
  185.  
  186.       On transmission, when the Protocol field is compressed to a single
  187.       octet, the NLPID is omitted.
  188.  
  189.       On reception, the NLPID field is examined.  If it is not the PPP
  190.       NLPID value, then it is expected to be a valid PPP Protocol value.
  191.  
  192.       The Protocol field value 0x00cf is not allowed (reserved) to avoid
  193.       ambiguity when Protocol-Field-Compression is enabled.
  194.  
  195.  
  196. 3.  In-Band Frame Format Detection
  197.  
  198.    For Permanent Virtual Circuits (PVCs), the NLPID and PPP Protocol
  199.    fields easily distinguish the PPP encapsulation.
  200.  
  201.    Initial LCP packets contain the sequence cf-c0-21 following the
  202.    header.  When a PPP LCP Configure-Request packet is received, the
  203.    link enters Link Establishment phase.
  204.  
  205.    Older implementations might contain the NLPID value CC hex, which is
  206.    used for IP.  Other ISO conformant implementations might contain
  207.    other NLPID values, such as 80 hex (SNAP), or 81 hex (CLNP).  Such
  208.    values indicate that the link is not properly configured for PPP
  209.    operation.
  210.  
  211.  
  212. 4.  Out-of-Band signaling
  213.  
  214.    Support for Switched Virtual Circuit (SVC) call setup and clearing is
  215.    not required.
  216.  
  217.    The first octet in the Call User Data (CUD) Field (the first data
  218.    octet in the Call Request packet) is used for protocol
  219.    demultiplexing, in accordance with the Subsequent Protocol Identifier
  220.  
  221.  
  222.  
  223. Simpson                  expires in six months                  [Page 3]
  224. DRAFT                         PPP in X.25                      July 1993
  225.  
  226.  
  227.    (SPI) in ISO/IEC TR 9577 [5].  This field contains a one octet
  228.    Network Layer Protocol Identifier (NLPID), which identifies the
  229.    network layer protocol encapsulated over the X.25 virtual circuit.
  230.    The CUD field MAY contain more than one octet of information, and
  231.    receivers MUST ignore all extraneous octets in the field.
  232.  
  233.    The PPP encapsulation MUST be indicated by a value of CF hex.  Other
  234.    values of the CUD are beyond the scope of this specification.
  235.  
  236.  
  237. 5.  Configuration Details
  238.  
  239.    The accidental connection of a link to feed an X.25 multipoint
  240.    network SHOULD result in a misconfiguration indication.
  241.  
  242.    The following Configuration Options are recommended:
  243.  
  244.       Magic Number
  245.       Link Quality Monitoring
  246.       Protocol Field Compression
  247.  
  248.    The standard LCP configuration defaults apply to X.25 links, except
  249.    MRU.
  250.  
  251.    To ensure interoperability with existing X.25 implementations, the
  252.    default Maximum-Receive-Unit (MRU) is 1600 octets [4].  The basic
  253.    HDLC header is significantly shorter than the full-sized X.25 header,
  254.    which may give additional leeway in buffer management.
  255.  
  256.    The typical network feeding the link is likely to have a MRU of
  257.    either 1500, or 2048 or greater.  To avoid fragmentation, the
  258.    Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
  259.    exceed 1500, unless a peer MRU of 2048 or greater is specifically
  260.    negotiated.
  261.  
  262.    The X.25 packet size is not directly related to the MRU.  Instead,
  263.    Protocol Data Units (PDUs) are sent as X.25 "complete packet
  264.    sequences".  That is, PDUs begin on X.25 data packet boundaries and
  265.    the M bit ("more data") is used to fragment PDUs that are larger than
  266.    one X.25 data packet in length.
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Simpson                  expires in six months                  [Page 4]
  279. DRAFT                         PPP in X.25                      July 1993
  280.  
  281.  
  282. Security Considerations
  283.  
  284.    Security issues are not discussed in this memo.
  285.  
  286.  
  287. References
  288.  
  289.    [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
  290.          progress.
  291.  
  292.    [2]   CCITT Recommendation X.25, "Interface Between Data Terminal
  293.          Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
  294.          for Terminals Operating in the Packet Mode on Public Data
  295.          Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.
  296.  
  297.    [3]   Simpson, W. A., "PPP HDLC Framing", work in progress.
  298.  
  299.    [4]   Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect
  300.          on X.25 and ISDN in the Packet Mode", RFC 1356, August 1992.
  301.  
  302.    [5]   ISO/IEC TR 9577, "Information technology - Telecommunications
  303.          and Information exchange between systems - Protocol
  304.          Identification in the network layer", 1990 (E) 1990-10-15.
  305.  
  306.  
  307. Acknowledgments
  308.  
  309.    This design was inspired by the paper "Parameter Negotiation for the
  310.    Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
  311.    University of California, Berkeley, 1992, unpublished.
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Simpson                  expires in six months                  [Page 5]
  334. DRAFT                         PPP in X.25                      July 1993
  335.  
  336.  
  337. Chair's Address
  338.  
  339.    The working group can be contacted via the current chair:
  340.  
  341.       Fred Baker
  342.       Advanced Computer Communications
  343.       315 Bollay Drive
  344.       Santa Barbara, California, 93111
  345.  
  346.       EMail: fbaker@acc.com
  347.  
  348.  
  349. Author's Address
  350.  
  351.    Questions about this memo can also be directed to:
  352.  
  353.       William Allen Simpson
  354.       Daydreamer
  355.       Computer Systems Consulting Services
  356.       P O Box 6205
  357.       East Lansing, MI  48826-6205
  358.  
  359.       EMail: Bill.Simpson@um.cc.umich.edu
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388. Simpson                  expires in six months                  [Page 6]
  389. DRAFT                         PPP in X.25                      July 1993
  390.  
  391.  
  392.                            Table of Contents
  393.  
  394.  
  395.      1.     Introduction ..........................................    1
  396.  
  397.      2.     The Data Link Layer ...................................    2
  398.         2.1       Frame Format ....................................    2
  399.         2.2       Modification of the Basic Frame .................    2
  400.  
  401.      3.     In-Band Frame Format Detection ........................    3
  402.  
  403.      4.     Out-of-Band signaling .................................    3
  404.  
  405.      5.     Configuration Details .................................    4
  406.  
  407.      SECURITY CONSIDERATIONS ......................................    5
  408.  
  409.      REFERENCES ...................................................    5
  410.  
  411.      ACKNOWLEDGEMENTS .............................................    5
  412.  
  413.      CHAIR'S ADDRESS ..............................................    6
  414.  
  415.      AUTHOR'S ADDRESS .............................................    6
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.